<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
<title>6.863 Project: Policy Parser</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>

	<!-- Begin Wrapper -->
	
		<div id="wrapper">
		
		<!-- Begin Header -->
			
			<div id="header">
				<h1>Policy Parser</h1>
				<h2>6.863 Spring 2008 Project</h2>		 
			</div>
			
		<!-- End Header -->
			
		<!-- Begin Strap -->
		
        <div id="strap">
<b>Policy Parser</b> &raquo; Future Directions</div>
		
		<!-- End Strap -->
		 
		<!-- Begin Navigation -->
		
		<div id="navigation">
			<ul id="menu">
				<li><a href="index.html">Home</a></li>
				<li><a href="intro.html">Intro</a></li>
			    <li><a href="#">Try It Now!</a></li>
	            <li><a href="implementation.html">Implementation</a></li>
                <li><a href="results.html">Results</a></li>
	            <li><a href="future.html">Future Directions</a></li>
	            <li><a href="download.html">Download Code</a></li>
 			 	<li><a href="members.html">Members</a></li>
			</ul>
		</div>
		
		<!-- End Navigation -->
		 
		<!-- Begin Content-->

		<div id="content">
		
		
		<div><b>Support the end-term goal of a fully automated policy compliance system: </b>The main goal of the Policy Parser is to allow a simple tool for
		people who are not
		proficient enough in authoring AIR policies in RDF. While we have achieved this goal successfully (for a limited category of sentences), more work remains
		 in the area of generating log files
		automatically (these are the input scenarios that need to be checked for compliance against the policies; while this was beyond the scope of this project, 
		it is important from the point of view of the eventual goal of which this project is a part of) and reason over them with the policies which have been 
		generated by the system to check for policy compliance.<div>

		<br/>
		

		<div><b>Support for more policy sentence templates: </b>The current implementation handles only a handful of sentence formats which includes the components 
		"ENTITY", "ACTOR", "ACTION", "DATA", "PURPOSE", "PASSIVE ENTITY" and "CONDITION"s. However many policies will have different 
		sentence templates which needs to be addressed in the Policy Parser. Ideally there should be an interface where a policy administrator should be 
		able to look at the available policies and modify them or add new policy templates to the system. Also support for pronouns as discussed in the 
		<a href="results.html">results.html</a> should be supported.</div>
		
		<br/>

<div><b> Handle more complicated grammatical constructs: </b> In our current implementation, we ignore many difficult issues such as correctly handling quantifiers, correctly associating pronouns ("he", "she" etc.) with the nouns used in the sentence (e.g. in the sentence "Police may search homes if they have a warrant to do that", 'they' refers to 'Police' and 'that' refers to 'searching homes'). We also don't correctly handle some common grammatical constructs, e.g. ditransitive verbs (verbs with both a primary and a secondary object) in the 'purpose' and 'condition'. This can be done fairly easily, but has not been done here because of the limited time frame for this project.
		</div><br/>
		
		<div><b>Extending the lexicon: </b>Currently the interface to the user only allows to select a particular domain ontology. 
		However, the user should have the freedom to
		define an ontology and add new terms into an existing ontology. Also this requires extending the lexicon used in parsing the sentence. 
		Also, the lexicon may be designed more carefully so that it faithfully follows the etymology of each word and allows related words to be 
		easily associated with each other without needing to define additional ontologies (relating "criminal" with "crime" or "investigation" with 
		"investigate", which are cases we handle, are examples of this).</div>

		<br/>

<div><b>Devise better strategies to handle ambiguous parses </b> As discussed in class, using context free grammars for parsing has the drawback of
 potentially yielding multiple parse trees for a given sentence. We handle this currently by using some heuristics in the Policy Interpreter to choose 
 one parse. While this has given reasonably good results thus far, it is likely that we will need more sophisticated ways of handling ambiguity if we
  want to parse a wider variety of sentences.
</div><br>
		
		<div><b>Give more meaningful error messages: </b> The user might be interested in knowing the exact point of failure when a sentence could not be 
		parsed correctly to an AIR policy written in RDF. For example the failure could be due to the fact a <b>particular</b> word used in the sentence is
		not in the lexicon, or the sentence is written in an unknown template, or the "features" extracted by the PolicyInterpreter is not found in the 
		domain ontology or any combination of these. Currently there is no robust mechanism of letting the user of the point of failure. However including
		such a feature would be beneficial. 
		</div>
		
		<br/>
		
		<div><b>Show the user policies in the current "Online Policy Store": </b>Users may be curious as to see what policies have already been generated 
		from the system. Thus, showing them the contents of the current "Online Policy Store" which could be a single centralized location or strewn acorss
		few locations would be useful.
		</div>
		
		<br/>
		
		<div><b>Improvements to the rendering of the AIR reasoner output: </b>Unfortunately the output given in <a href="try.html#fig6">Figure 6</a> in the 
		<a href="try.html">
		Try it now!</a> page does not give a simple "yes" or "no" answer from the AIR reasoner. We believe we could imporve the  user interface
		such that we could obtain an output such as the following, so that the entire system will be much more intuitive to use and understand.</div>
		
		<br/>
		
		<a href="images/expected_output.png" target="_blank">
		<div style="text-align: center;">
        	<img src="images/expected_output.png" width="100%" alt="Expected Output from the AIR reasoner to be viewed from the Tabulator"/>
            <p>Figure 1: Expected Output from the AIR reasoner to be viewed from the Tabulator</p><br/>
        </div>
        </a>

		
		</div>
		
		<!-- End Content -->
		
		<!-- Start Footer -->
		
		<div id="footer">
		</div>
		
		<!-- End Footer -->
		 
    </div>
	
    <!-- End Wrapper -->
	
</body>
</html>
